home *** CD-ROM | disk | FTP | other *** search
- Path: news.production.compuserve.com!news
- From: Dave Hand <70621.3624@CompuServe.COM>
- Newsgroups: comp.lang.c,comp.lang.c++
- Subject: Poor floating point code in BC++
- Date: 2 Jan 1996 00:00:42 GMT
- Organization: Singular Software, Inc.
- Message-ID: <4c9sja$gke$1@mhafc.production.compuserve.com>
-
- BC++ 4.51 seems to generate very poor floating point code. I would be
- interested to know how well other compilers do on the following
- examples. These were compiled using options: i486 CPU, fast floating
- point, optimize for speed, large memory model.
-
- main()
- {
- double x,y,z;
- int n;
-
- x = 4.5;
- y = 10.7;
- n = x;
- z = x * y;
- }
-
- Plain arithmetic, such as z = x * y, is generated inline as one would
- expect. You would think the line n = x would be quite fast. However,
- it generates a function call:
-
- n=x;
- wait
- fld qword ptr[bp-0A]
- call far FTOL@
- mov [bp-02],ax
-
- where FTOL@ is a very long function for what is does:
-
- push bp
- mov bp,sp
- sub sp,000A
- fnstcw word ptr[bp-02]
- fwait
- mov al,[bp-01]
- or byte ptr[bp-01],0C
- fldcw word ptr[bp-02]
- fistp qword ptr [bp-0A] <<-- here is the meat of it.
- mov [bp-01],al
- fldcw word ptr[bp-02]
- mov ax,[bp-0A]
- mov dx,[bp-08]
- mov sp,bp
- pop bp
- retf
-
- I was trying to optimize some graphics code. The net result is that
- in many graphics calculations, the final conversion from world
- coordinates to screen coordinates is the overwhelming majority of the
- time. There are many other places where BC++ seems to generate very
- bad floating point code (unless I'm missing some important point). I
- would very much like to know if other compilers do a better job (or
- set me straight as to why the above code makes sense).
-